前兩天，我確認了平均分攤與零頭分配的結果。今天換一個角度：如果使用者沒有照預期填資料，系統會怎麼辦？姓名留白、重複加入同一個人，或在金額裡輸入小數與文字，都是很容易發生的操作。分錢工具除了算得對，也需要在資料不合理時停下來，告訴使用者如何修正。

我先請 AI 檢查現有程式，再準備錯誤輸入與預期結果，分別驗證計算模組和瀏覽器表單。原型已經有輸入驗證，因此今天的重點是確認它是否真的有效，以及修正後能不能繼續使用。

第一個測試是新增成員。在瀏覽器裡，分別輸入空白、只有空格、已存在的「小明」，以及前後多了空格的「 小明 」。四種情況都被拒絕，成員數維持三人，畫面顯示「姓名不可空白或重複，最多 30 字。」這也確認了表單會先去掉姓名前後的空格，再檢查是否重複。

接著把姓名改成「 測試夥伴 」，這次成功加入，畫面顯示的是去除前後空格的「測試夥伴」，成員數變成四人，原本的錯誤提示也清除了。對使用者來說，驗證不能只有阻擋；把資料改正以後，應該能接著完成原本想做的事。

第二個重點是支出金額。目前的規則是新台幣整數元，範圍為 1 到 999,999,999。因此，我們在瀏覽器測試了九種輸入：空白、只有空格、零、負數、小數、英文字母、帶千分位逗號的數字、科學記號，以及超過上限的金額。這些都沒有成功儲存。

這裡有一個值得記下來的細節：輸入「1,000」對人來說很容易理解，但目前表單只接受不含逗號的整數格式，所以必須填成「1000」；「1e2」雖然能被 JavaScript 轉換成數字，也不符合這個表單接受的格式。程式會先檢查原始文字，再轉成數值，避免只靠數字轉換來判斷輸入是否正確。

不同錯誤也有不同提示。格式不符合時，畫面要求填寫不含小數或其他符號的整數元；零元與超過上限的金額，則顯示允許的範圍。這些訊息至少能指出目前接受的格式與數值範圍，不會只留下沒有原因的「儲存失敗」。

接著，我把金額改成有效的 100 元，但將支出名稱只填空格。系統顯示「請填寫支出名稱，最多 60 字。」修正名稱後，再取消所有分攤成員，則出現「請至少選一位分攤成員。」這兩項檢查提醒我，金額正確還不夠，一筆支出也需要有名稱，以及真正需要負擔費用的人。

測試完錯誤情況後，我重新選取全部成員，把金額填成前後帶空格的「 100 」，再儲存。這次成功新增一筆 100 元支出，四人各分攤 25 元。原本三筆範例合計 1,830 元，新增後變成四筆、合計 1,930 元，沒有因為前面多次按下儲存而多出其他帳目。

我也檢查了編輯失敗會不會影響原資料。把剛才的 100 元支出改成負五元，按下儲存後被拒絕，再取消編輯。回到帳本時，原支出仍然是 100 元，總筆數與總額也維持四筆、1,930 元。這確認了本次操作中，錯誤輸入沒有覆蓋已經儲存的帳目。

除了畫面操作，今天也直接執行了 27 項計算模組測試，全部通過。內容包含空白與重複姓名、字數及人數限制、無效金額、不存在的付款人、空白或重複的參與名單、錯誤分攤方式，以及自訂分攤的負數與合計不符。也確認了有效邊界，例如一元、金額上限、50 位成員，以及自訂分攤中的零元份額，都能被接受。

表單與計算模組的工作並不完全相同。表單需要處理使用者輸入的文字，例如去除前後空格、拒絕不支援的金額格式；計算模組則檢查傳入的資料是否符合規則。只測其中一層，不能直接代表另一層也正確，所以今天把兩者分開留下紀錄。

瀏覽器部分共完成 18 個檢查案例，包含錯誤輸入、修正後成功新增，以及錯誤編輯後保留原帳目。不過，這仍然是選定案例的驗證，沒有涵蓋所有裝置、輔助工具或完整操作流程。像是自訂分攤的部分邊界，今天只在計算模組中檢查，之後仍需要配合對應功能補上畫面測試。

目前的提示也還有改善空間。例如姓名錯誤使用同一句話涵蓋空白、重複與過長，未來可以分別指出原因；金額欄位也可以更早說明不接受逗號。這些是後續改善方向，今天沒有把尚未修改的介面寫成已完成成果。

第九天沒有修改產品程式，也沒有發布新版，而是確認既有驗證能擋下這些錯誤，並留下可重複執行的測試。這次讓我更清楚，可靠的分錢工具不只需要正確答案，也需要讓使用者知道資料哪裡有問題，並且在修正過程中保住原本的帳。

下一天會回到一場聚會有多筆支出的情境，檢查新增、編輯與刪除後，支出清單和結算結果是否能一起正確更新。